Business applications, such as Enterprise Resource Planning software, can consist of modular application components that are combinable to meet the needs of a specific business scenario. The application components and the process interactions between the application components can be modeled with the information required for implementation of the model. In some instances, certain application components may initially be combined in a particular configuration, but the configuration may need to be modified later by, for example, adding additional application components or replacing current application components. For example, a business scenario may require only a partial configuration with only a portion of all available application components but may later require a transition into a full configuration with additional application components.
In order to extend the functionality of a software system with application components, however, several tasks must be completed before introducing new application components or replacing application components. For example, configuration settings of the new application components and the master data required within the new application component must be maintained, and associated software processes must be reconfigured to include the new application component. Further, in order to maintain master data, the configuration settings and user interface of the new application component must already be available. Business documents are generally not sent to the new component for processing, however, because the component will not be fully functional unless the preparation steps have been completed. Thus, the addition of application components or the switch to a new process integration is delayed. In some instances, a business downtime may be applied to prepare new application components and to activate new process integrations. During the business downtime, however, the software system may be available for preparation tasks, but locked for other business related activities. Accordingly, many tasks must be delayed to implement a configuration change.
In order to decrease business downtimes, some implementations may move certain preparation tasks to a clone copy of the productive system. The productive system may then continue with normal business activity while the clone system prepares activation of application components and process integration. At the end of the preparation, a downtime is incurred to merge the new data and configuration back to the productive system and to switch to the new process integration. Migrating preparation tasks to a clone system, however, increases the costs of operation and requires extensive additional resources such as master data replication mechanisms and additional maintenance of master data.
Still further, predefined change scenarios may be created, and relevant process integration models are explicitly defined for each of the predefined change scenarios. At configuration time, process integration models belonging to a change scenario are only activated after the preparation phase of the change project is finished. In these implementations, however, business changes to a particular configuration of application components are required to follow the predefined change scenarios.